Network architecture

ABSTRACT

A telecommunications system is provided comprising a mobile device and an IP Multi-media Sub-system (IMS), the mobile device being connected to a Public Land Mobile Network (PLMN). The mobile device is adapted to: identify if the PLMN supports Customised Applications for Mobile network Enhanced Logic (CAMEL) and, upon receiving an attempt to initiate a call to a dialled number, if the PLMN supports CAMEL, allow the call to proceed. The PLMN is adapted to: receive a request to connect a call from the mobile device; invoke a CAMEL service trigger indicating that the call should be routed to the IMS; and, route the call to the IMS. The IMS is adapted to: control the call; and, refer the call to a call storage system for call storage. A mobile device, IP Multi-media Sub-system and method in a mobile device are also provided.

CROSS REFERENCE TO RELATED APPLICATIONS

This application is a continuation of U.S. patent application Ser. No.13/437,646 filed on Apr. 2, 2012 and entitled “NETWORK ARCHITECTURE,”which claims priority to United Kingdom Application Number 1105565.4,filed on Apr. 1, 2011, both of which are incorporated herein byreference in their entirety.

BACKGROUND OF THE INVENTION

Legislation and regulation in many countries and states mandates callrecording for banks, insurance companies, trading houses and otherfinancial institutions. Since mobile telephones are increasingly beingused for communications in such institutions, it has become highlydesirable, and in some cases necessary, to provide efficient andeffective recording of calls and communications made usingtelecommunications networks.

An example of such regulation is the regulation set by the UK'sFinancial Services Authority, which requires that all calls and allelectronic communications sent to and from the mobile telephonesbelonging to those employees of Financial Institutions that trade inshares and wholesale financial products be recorded and stored for aminimum of 6 months. Since these records may need to be used as evidencein criminal prosecutions, the storage system must ensure that therecordings are secure and tamper-proof. Calls and electroniccommunications that can not be recorded must not be allowed.

It may also be desirable to record mobile telephone calls for forensic,crime prevention or other purposes. Although recent financial regulationhas highlighted the need for telephone call recording, there are ofcourse numerous reasons why recording and subsequent checking ormonitoring of calls and other communications may be advantageous.

A common requirement of call recording solutions is that mobile usagecharges be attributed to the mobile subscriber's post-pay price plan,thus leaving the customer's charging structure unchanged.

Known call recording solutions have typically fallen into twocategories: network-based (mobile phone agnostic) recording and mobileclient-based (network agnostic) recording. Both types of system sufferfrom inherent drawbacks. These mobile call and SMS recording solutionsare commonly offered by third-party system integrators, i.e. systemswhich integrate with conventional telecommunications networks.

In the network based system, complications occur when roaming or whencommunications are instigated between external mobile telephones andtelephones comprising part of a private branch exchange or PBX. Roamingis particularly problematic since many networks do not provide thefunctionality that allows for efficient recording, or if they do,complicated agreements are required between network operators in orderto implement such functionality at the local level.

Additionally, it has been common, either intentionally to circumvent therecording systems or otherwise, for users to replace the SIM in theirhandsets with another SIM. The system which may be configured to recordonly those communications associated with a particular SIM, may nolonger record these communications.

Two fundamental issues have meant that it is not currently possible fornetwork operators to offer a network-based (mobile phone agnostic)solution.

Firstly, the recordal of Mobile Originating (MO) SMS is not possiblewithout the necessary SMSC functionality. Additionally, MobileTerminating (MT) SMS is not possible without deploying “SMS Home NetworkRouting”.

Secondly, the requirement to record MO calls whilst roaming is notpossible without Customised Application for Mobile network EnhancedLogic (CAMEL) service capability. It is possible to prevent the mobilesubscriber from roaming onto any Public Land Mobile Network (PLMN) thatdoes not support CAMEL. Whilst this approach might not be toorestrictive in most European countries, this approach severely restrictsroaming opportunities in North America and entirely removes all roamingopportunities in China.

As a result of the SMS issues, it is necessary to employ a mobileclient-based system to perform SMS recording. The alternative option ofnot provisioning SMS services on mobile subscriptions for financialinstitutions is highly undesirable.

Various client-based solutions may address the above issues, but carryinherent problems of their own. Indeed most of the mobile call and SMSrecording solutions being offered by third-party system integrators areentirely mobile client-based (network agnostic) solutions. In the main,these solutions are not entirely without flaw and the user experience isoften poor.

In a known client based system, a client installed on the mobile devicerecords each conversation through use of the devices internal microphoneor other means. Typically, the stored conversation may then be forwardedto a remote storage server using a data connection on the device. Thisis undesirable for a number of reasons, including the high use of databandwidth, which is particularly relevant when roaming. Additionally,the SIM of the user may commonly be transferred to another handset. Thishandset may not have the client installed and so call recording may nolonger be possible. Further, client-based systems must be redesigned foreach handset type, in fact some handsets may not allow clients to accesskey systems required in order to effectively record conversations.

Another known client-based call recording system is described inWO2009/068861, WO2011/001171 and WO2011/107806, for which the applicantis Compliant Phones Ltd (CPL). The CPL system comprises an electroniccall centre or gateway. A client on the device intercepts outbound callsand instead dials an access number. Once connected to the call centre,the client transmits the originally dialled number to the call centrewhich connects the call. The call centre then intercepts thecommunication and stores it as it routes the communication, therebyacting as a ‘middle man’.

There is a need for a system and method for recording communications fora particular user or group of users. Preferably, the recordal should notbe affected by roaming, SIM replacement or removal and should not affectcurrent charging structures.

SUMMARY OF THE INVENTION

According to a first aspect of the present invention there is provided atelecommunications system comprising a mobile device and an IPMulti-media Sub-system (IMS), the mobile device being connected to aPublic Land Mobile Network, PLMN, wherein: the mobile device is adaptedto: identify if the PLMN supports Customised Applications for Mobilenetwork Enhanced Logic, CAMEL; and, upon receiving an attempt toinitiate a call to a dialled number, if the PLMN supports CAMEL, allowthe call to proceed; the PLMN is adapted to: receive a request toconnect a call from the mobile device; invoke a CAMEL service triggerindicating that the call should be routed to the IMS; and, route thecall to the IMS, and, the IMS is adapted to: control the call; and,refer the call to a call storage system for call storage. The mobiledevice may be further adapted to, upon receiving an attempt to initiatea call to a dialled number and if the PLMN does not support CAMEL,prevent the call from proceeding.

According to a second aspect of the present invention, there may beprovided a telecommunications system comprising a mobile device and anIP Multi-media Sub-system (IMS), the mobile device being connected to aPublic Land Mobile Network, PLMN, for routing a call, wherein the mobiledevice is adapted to: identify if the PLMN supports CustomisedApplications for Mobile network Enhanced Logic, CAMEL; upon receiving anattempt to initiate a call to a dialled number, if the PLMN does notsupport CAMEL, send a data message to the IMS including the diallednumber; receive a pseudo-roaming number from the IMS; and, initiate acall to the pseudo-roaming number, and, the IMS is adapted to: receive adata message including the dialled number; return a pseudo-roamingnumber associated with the IMS; receive the call; refer the call to acall storage system for call storage; and, connect the call to thedialled number.

The present invention thus provides a hybrid network assisted,client-based solution for the recording of mobile telephone calls. Themobile device can also be employed to overcome the dependency upon CAMELfor roaming. In contrast to a client-based system, the hybrid solutionprovides that all user charging components for the voice recordingsolution can be fully integrated with the mobile subscriber's bill.

Being a network-assisted (rather than a network agnostic) solution, thedescribed mobile call recording proposition can take advantage ofnetwork features, for example, INAP, CAMEL and USSD, to significantlyimprove the user experience for Mobile Originated (MO) and MobileTerminated (MT) call scenarios.

Additionally, the present invention provides quicker call set up than aknown IP Message call recording procedure, for example, less than 500ms. Compared to the known IP message call recording procedure, thepresent invention does not require IP data coverage to avoid DTMF fallback and will not cause “ghost calls” resulting from mobile networkcongestion. Use of an IMS in the system avoids PSTN interconnect chargeincurred by incurred by the network operator in order to get the call tothe storage solution. Further, the operator can differentially chargeon-VPN and on-Net mobile calls and can charge the mobile originated calldirectly to the originating user.

Since the recording is routed through the network, the system ensuresthat the user is still a subscriber and respects the mobile subscriber's“international calls” and “premium rate calls” bars. The user's MobileOriginated calls can also be recorded even if they remove their SIM fromtheir authorised mobile handset.

The telecommunications system may further comprise a SubscriberIdentification Module, SIM, for inserting into the device, the SIMadapted to prevent call connection if an International Mobile EquipmentIdentity, IMEI, of the mobile device does not match an expected IMEI.This functionality ensures that Mobile Originated calls whilst roamingin a non-CAMEL compliant PLMN will always be recorded, even if the SIMis inserted into a device that does not provide for client based callrecording.

Additionally, when the mobile device sends an SMS message, the mobiledevice may be further adapted to store the SMS message by: sending an IPdata message corresponding to the sent SMS message to an SMS storagesystem where the connected PLMN is a home PLMN and where IP datacoverage is available, and, sending a replica of the sent SMS message tothe SMS storage system where the mobile device is roaming on a foreignPLMN or where IP data coverage is not available. If the destination ofthe SMS matches one of a predetermined list of destinations stored onthe mobile device, the mobile device may not store the SMS. In this way,a system for the recordal of SMS message is provided, and, additionally,messages that may be directed to network based services may not berecorded.

The identifying if the PLMN supports CAMEL may comprise evaluating thePLMN against a list of PLMNs that support CAMEL stored on the mobiledevice. Further, the IMS may be further adapted to send a list of PLMNsthat support CAMEL to the mobile device, and wherein the mobile deviceis adapted to store the list upon receipt of the list from the IMS. Inthis way, if a PLMN is amended to support CAMEL, the device may use theCAMEL procedures to record the call.

Additionally, if the dialled number matches one of a predetermined listof numbers stored on the mobile device, the mobile device may be adaptedto allow the call to proceed irrespective of whether the PLMN supportsCAMEL. Thus, emergency services calls are not interfered with.

The IMS may be further adapted to audibly indicate to one or moreparties of the call that the call is being recorded. This may benecessary to comply with privacy requirements.

The mobile device of the second aspect of the present invention may befurther adapted to: upon receiving an attempt to initiate a call to adialled number, if the PLMN supports CAMEL, allow the call to proceed,the telecommunications system further comprises the PLMN, wherein thePLMN is adapted to: receive a request to connect a call from the mobiledevice; invoke a CAMEL service trigger indicating that the call shouldbe routed to the IMS; and, route the call to the IMS, and the IMS isfurther adapted to: control the call; and, refer the call to a callstorage system for call storage.

A mobile device adapted for use in the telecommunications system of anyaspect of the present invention may also be provided. An IP Multi-mediaSub-system (IMS) adapted for use in the telecommunications system of anyaspect of the present invention may also be provided.

According to a third aspect of the present invention, there may beprovided a method in a mobile telecommunications device, comprising:identifying if the PLMN supports Customised Applications for Mobilenetwork Enhanced Logic, CAMEL; upon receiving an attempt to initiate acall, if the PLMN supports CAMEL, allowing the call to proceed; if thePLMN does not support CAMEL, sending a data message to the IMS includingthe dialled number; receiving a pseudo-roaming number from the IMS; and,initiating a call to the pseudo-roaming number.

According to a fourth aspect of the present invention, there may beprovided a telecommunications network comprising a core network and anIP Multi-media Sub-system (IMS), wherein: the core network is adaptedto: receive a call including a requested destination; if the call shouldbe recorded, invoke a Customised Applications for Mobile networkEnhanced Logic, CAMEL, service; and, refer the call to the IMS, andwherein, the IMS is adapted to: receive the call from the core network;initiate a conference call to a media storage platform; and, connect thecall to the requested destination.

According to a fifth aspect of the present invention, there may beprovided a mobile telecommunications device being connected to a PublicLand Mobile Network, PLMN, wherein the mobile device is adapted to, whenthe mobile device sends an SMS message, store the SMS message by:sending an IP data message corresponding to the sent SMS message to anSMS storage system, where the connected PLMN is a home PLMN and where IPdata coverage is available, and, sending a replica of the sent SMSmessage to the SMS storage system where the mobile device is roaming ona foreign PLMN or where IP data coverage is not available.

According to a sixth aspect of the present invention, there may beprovided a Subscriber Identification Module, SIM, for inserting into amobile device, the SIM adapted to prevent call connection if anInternational Mobile Equipment Identity, IMEI, of the mobile device doesnot match an expected IMEI such that calls made using the SIM can beprevented when made using an unauthorised mobile device.

DETAILED DESCRIPTION OF THE DRAWINGS

An example of the present invention will now be described in detail withreference to the accompanying drawings, in which:

FIG. 1 shows a first embodiment of the present invention for MobileOriginated recording in the home PLMN;

FIG. 2 shows an alternative embodiment of the present invention forMobile Originated recording in the home PLMN;

FIG. 3 shows a further embodiment of the present invention for MobileOriginated recording in a foreign PLMN;

FIG. 4 shows a further embodiment of the present invention for MobileOriginated recording in a foreign PLMN;

FIG. 5 shows a further embodiment of the present invention for MobileOriginated recording in a foreign PLMN;

FIG. 6 shows a further embodiment of the present invention for MobileOriginated recording in a foreign PLMN;

FIG. 7 shows a further embodiment of the present invention for MobileOriginated recording in a foreign PLMN;

FIG. 8 shows a further embodiment of the present invention for MobileTerminated recording;

FIG. 9 shows a further embodiment of the present invention for MobileTerminated recording;

FIG. 10 shows a further embodiment of the present invention for callforward recording;

FIG. 11 shows a further embodiment of the present invention for SMSrecording;

FIG. 12 shows a further embodiment of the present invention for userprovisioning;

FIG. 13 shows a further embodiment of the present invention for handsetchange; and,

FIG. 14 shows a further embodiment of the present invention for clientactivation.

GLOSSARY

-   A-party Calling party-   ACM Address Complete Message, a Signalling System#7 message-   APN Access Point Name-   AS Application Server-   ASAP Automatic Service Activation Programme, a service provisioning    system for IMS-based services-   ASN1 Abstract Syntax Notation 1-   BAN Billing Account Number-   BES Blackberry Enterprise Server-   BCS Business Communication Suite, allows non-SIP terminals (using    the GSM network) to be able to invoke services from the IMS Core and    SIP Application Servers-   B-party Called Party-   BSC Base Station Controller-   CA Call Anchoring, term used to describe the concept whereby call    control for the mobile is performed by an entity outside of the    Visited Mobile Switching Centre-   CAMEL Customised Application for Mobile network Enhanced Logic-   CD Call Deflection-   CDR Call Detail Record-   CFB Call Forward Busy-   CFNR Call Forward No Reply-   CFNRc Call Forward Not Reachable-   CFU Call Forward Unconditional-   CgPN Calling Party Number-   CLI Calling Line Identity-   CLIP Calling Line Identity Presentation-   CLIR Calling Line identity Restriction-   CORP_ID Corporate Identity, the customer reference in a retail    billing system-   C-party Diversion destination party-   CPE Customer Premises Equipment-   CS Circuit Switched-   CSD Circuit Switched Data-   CTN Cellular Telephone Number, used to describe a mobile    subscription-   CUR Common User Repository, database holding service related    subscription data-   DTMF Dual Tone Multi-Frequency-   DTAP Direct Transfer Application Part, the GSM call control    signalling protocol which was derived from the ISDN signalling    protocol.-   E164 A telephone number in the format defined in ITU-T    Recommendation E.164-   EMM Ericsson Multi-Mediation, IMS CDR mediation system-   FSA Financial Services Authority-   FTP File Transfer Protocol-   GMSC Gateway Mobile Switching Centre-   GSM Global System for Mobile communications-   HEC Hosted Enterprise Communications, Fixed Mobile Convergence    system for multi-national corporate customers-   HLR Home Location Register-   IM Instant Messaging-   IMEI International Mobile Equipment Identity-   IMS IP Multi-media Sub-system-   IP Internet Protocol-   ISAAC International Subscriber Administration And Control system, a    subscriber provisioning system-   ISDN Integrated Services Digital Network-   ISDN-30 BT's Integrated Services Digital Network Primary Rate    Interface product-   IWF Inter-Working Function-   MO Mobile Originated-   MCF Mobile Call Forward-   MGC Media Gateway Controller, a component of an IMS-   MMS Multimedia Messaging Service-   MRF Media Resource Function, a component of an IMS-   MSC Mobile Switching Centre-   MSISDN Mobile Station International Subscriber Directory Number-   MT Mobile Terminated-   MVPN Mobile Virtual Private Network, a community of mobile    subscriptions-   NGIN Next Generation Intelligent network Node-   OICK Originating Intelligent networking Category Key-   OMO Other Mobile Operator-   On-NET A call between two subscriptions on the same mobile network    (but not in the same Mobile VPN)-   On-VPN A call between two subscriptions within the same Mobile VPN    (and typically within the same customer Billing Account)-   PLMN Public Land Mobile Network-   PNP Private Numbering Plan-   PS Packet Switched-   PSTN Public Switched Telephone Network-   RADIUS Remote Authentication Dial In User Service-   RCSe Rich Communications Suite enhanced-   SBC Session Border Controller, a component of an IMS-   SIM Subscriber Identity Module-   SIP Session Initiation Protocol-   SMEs Small and Medium Enterprises-   SMS Short Message Service-   SOC Service Order Code, a subscription feature that is attached to    the subscription-   SSL Secure Sockets Layer-   TICK Terminating Intelligent networking Category Key-   UK ISUP United Kingdom Integrated Services User Part variant of    signalling system#7-   USSD Unstructured Supplementary Service Data-   VMSC Visited Mobile Switching Centre

DETAILED DESCRIPTION

The following describes the concepts of an operator group operated,network-assisted, client-based, mobile call and SMS recordingproposition.

The calls and SMS messages pertaining to the mobile users that aresubscribing to this service will be recorded, stored and retrieved fromcustomer-owned Customer Premises Equipment (CPE) for enterprise entities(although a network hosted call and SMS recording, storage and retrievalsystem may also be available for those entities that prefer thisvariant).

A smart phone client will actively participate in Mobile Originated (MO)and Mobile Terminated (MT) SMS recording functions and will also allowMO call recording to be performed when the mobile user is roaming onthose foreign PLMNs which do not support Customised Application forMobile network Enhanced Logic (CAMEL).

The example described herein proposes to use an operator groupcontrolled Next Generation Intelligent network Node (NGIN) andApplication Server as the starting point for the Mobile Call Recordingservice. In this way the solution is developed once and re-used for anumber of operators. It will be understood that the concepts describedare equally applicable to a single operator network or a group ofnetworks.

The conceptual, exemplary, design includes the following features:

-   -   i) Support for recording of MO calls in home PLMN, in foreign        PLMNs that supports CAMEL and in foreign PLMNs that don't        support CAMEL, that is, will operate on any PLMN that has a        roaming agreement with the home operator.    -   ii) Guaranteed recording of calls (such that if the call can not        be recorded, the call will not be established),    -   iii) Reporting each IMEI update for the mobile subscriber and        generating an alert notification to the entities customer's        administrator when the IMEI is not one that has been declared by        the entity,    -   iv) SIM Toolkit application on the mobile subscriber's SIM which        verifies that the IMEI of the mobile handset corresponds to that        registered within the SIM toolkit application.    -   v) The provision of an “intrusion warning tone” for Mobile        Originated and Mobile Terminated calls and the provision of a        post-connection announcement for Mobile Call Forwarded calls, to        indicate to all parties involved in the call that the call is        being recorded,    -   vi) If the mobile subscription has both a restricted roaming        list (comprising only CAMEL compliant PLMNs) and no SMS services        provisioned, the solution becomes entirely network-based, i.e.        the mobile user does not require the Client installed on their        mobile phone, nor the SIM toolkit application installed on their        SIM.

The described exemplary implantation may include the followingcomponents:

A Mobile smart phone client which will participate in MO & MT SMSrecording and MO call recording (or MO call anchoring) on those foreignPLMNs that do not support CAMEL.

A mobile call recording service logic and new USSD interface on the NGINor Application Server.

A SIP connectivity which may provide connectivity to deliver call mediafrom the IMS to the customer's call and SMS recording and storage system(CPE or Hosted).

A CPE-based or Hosted call and SMS recording and storage function whichmay receive call media from the SIP trunk and receive SMS from theCentralised SMS distribution server and, providing that the other partyinvolved in the call or SMS is not on the user's personal white-list,record it and store it.

A CPE-based/Hosted call and SMS retrieval function which may allowcustomers to access the call media and SMS messages for their users.

A known SMS Aggregator which may send the copied SMS messages to thecentralised SMS distribution server.

A centralised SMS distribution server which may reformat SMS and sendthem to the relevant customer's call and SMS storage system and willreceive IMEI update reports and send them to the relevant customer'scall and SMS recording and storage system.

A centralised client management server which may update the CAMELcompliant PLMN list on the client (“Pulled” from Client using IPconnectivity) and activate and passivate the client, update the networkwhite list of SMS senders and update the network white list of dialledtelephone numbers, change the IP Message addresses used for SMSrecording and change the SMS Aggregation address for SMS recording andprovision the mobile subscriptions into the Centralised SMS distributionserver.

A known ISAAC which may provision the call and SMS recording mobilesubscription on the mobile network for example HLR and Voicemail etc)and will provision the call and SMS recording mobile subscriptions intothe Centralised Client Management server.

A known Corporate Gemini which will provision the call and SMS recordingmobile subscription within the retail billing system and initiate theprovisioning of the call and SMS recording mobile subscription on themobile network via ISAAC.

A mobile device manager, for example, the BES server in the case ofBlackberry mobile handsets, to load the client onto the Smart Phone andto prevent unauthorised mobile clients such as Skype, IM etc., beingloaded on to the Smart Phone.

An HLR which may generate a notification via the Centralised SMSDistribution server to the CPE-based or Hosted call and SMS recordingand storage platform when the Mobile Subscriber's IMEI is updated.

A SIM toolkit application installed on SIM will verify the IMEI of thehandset for each Mobile originated call attempt in order to preventunrecordable calls being originated whilst the SIM being installed in amobile device whilst roaming on a non-CAMEL compliant PLMN

A network voicemail platform which does not permit “direct deposit”(this is necessary to prevent messages being deposited without beingrecorded and then being collected from another device) and does notpermit Call Return (this is necessary because that the destinationtelephone number of the Call Return call wouldn't be conveyed to theCall recording platform).

Three, equally viable, alternative mobile call recording architecturesare described as exemplary implementations of the present invention.

The first architecture, which is implied throughout the remainder of thedocument, sees the service intelligence shared between theNGIN/Application Server and a combined call recording and storagesystem. The NGIN/Application Server is responsible for controlling the“real” call and generating the recording-leg call to the combined callrecording and storage system. The combined call recording and storagesystem is responsible for controlling the “intrusion warning tone” andthe “post-connection announcement” and responsible for deciding whetherto record the call. In this architecture, the combined call recordingand storage system may be customer premise-based or may be hosted by thenetwork operator.

The second architecture sees the service intelligence almost entirelywithin the NGIN/Application Server. The NGIN/Application Server isresponsible for controlling the “real” call and generating therecording-leg call and controlling the “intrusion warning tone” and the“post-connection announcement”. The combined call recording and storagesystem is merely responsible for deciding whether to record the call. Inthis architecture, the combined call recording and storage system may becustomer premise-based or may be hosted by the network operator.

Like the second architecture, the third architecture sees the serviceintelligence almost entirely within the NGIN/Application Server. TheNGIN/Application Server is responsible for controlling the “real” calland generating the recording-leg call to the Call Recording function andcontrolling the “intrusion warning tone” and the “post-connectionannouncement”. However, in this third architecture, the Call Recordingfunction and Call Storage function are no longer performed on the sameelement. Instead, the Call Recording function is performed within theoperator's estate. On completion of the ‘real’ call, the Call Recordingfunction will send a file containing a copy of the call content and callrelated details to the Call Storage function. The Call Storage functionis merely responsible for deciding whether to store the call. In thisarchitecture, the Call Storage system may be customer premise-based ormay be hosted by the network operator.

The description herein suggests that call media delivery to the CallRecording platform should be achieved using one single SIP connection(and the IMS MRF used to perform the conference function).Alternatively, call media delivery to the customer's Call Recordingplatform could be achieved using two SIP connections from the SBC (whereone connection is for the A-Party Tx and the other connection is theB-party Tx) and the Call Recording platform used to associate these twoSIP call legs. Although this alternative arrangement would not requirethe MRF and would offer an opportunity for “stereo” media recordings, itwould consume twice the bandwidth of the SIP trunk and would elevate theSIP Trunk connection to the Call Recording platform as critical to thesuccess of the “real” call, even when the customer had determined thatcall recording was only required to be “best endeavours” (rather than“Compelled”). It would also allow the Call recording platform to returnthe intrusion warning tone to the appropriate call leg. Consequently, itis considered that this alternative procedure to deliver the call mediato the Call Recording platform only be preferable for the thirdArchitecture option, i.e. it is not deployed when the Call Recordingplatform is located on the customer's premise.

Exemplary call and SMS recording implementations will now be describedin detail.

Mobile Originated Call (on Home Network)

FIG. 1 illustrates an exemplary implementation of the present inventionfor handling and recording Mobile Originated calls when on the homenetwork. The mobile user first dials the telephone number of B 16(“01635677899”). The client determines that intervention is notrequired, thus allowing the mobile 15 to send “01635677899” to the VMSC17 (step 10). The VMSC 17 sends call to the IMS 18 (step 11). The IMS 18refers the call to the AS 19 (step 12). The AS 19 instructs the IMS 18to initiate a conference call to the Media Storage Platform 20 (step13). The AS 19 instructs the IMS to initiate a real call to B 16(“01635677899”, step 14). If the call encounters any ISDN/GSM callforwarding then the AS 19 will notify this to the Media storage platform20.

A more detailed embodiment of MO recording on the home network will nowbe described. This detailed embodiment is illustrated in FIG. 2. First,the client will analyse the dialled digits to determine whether anemergency telephone number eg 999, 112, 911 etc. has been dialled. If anemergency telephone number has been dialled, the client will not modifythe dialled digits or participate further in the call setup but willallow the call to proceed unhindered. If an emergency telephone numberhas not been dialled, the client will determine what network 27 themobile subscriber is currently registered on.

Recognising that it's not roaming, the client shall instruct the mobiledevice to send the DTAP SETUP message 21 with the Called Party BCDNumber information element's Type of Number as dialled eg“international” or “unknown” and Number Digits comprising only the “userdialled destination digits”.

A SIM toolkit application shall verify that the IMEI corresponds to theuser's registered handset (which has the client installed). If the IMEIis not verified, the call attempt will not be allowed. Otherwise theDTAP SETUP message 21 is allowed to be sent to the VMSC.

The mobile subscription will have been provisioned with the INAP/CAMELservice trigger which will have been stored in the VLR.

The NGIN/AS 19 will receive the INAP/CAMEL IDP 22 from the VMSC 17 andwill store the Called Party BCD Number and Calling Party Numberparameter (including APRI) against a correlation Identity number andshall return a Pseudo-routing Number (comprising <HomeCountryCode><NationalNumberGroup> <Correlationidentity>) within the INAP/CAMELCONNECT 23 message.

In the event that a INAP/CAMEL signalling error occurs, the call attemptshall not be allowed to proceed i.e. the mobile subscriber's INAP/CAMELO-CSI parameter “default ch” shall be configured with the value“RELEASE”.

The VMSC 17 shall route the call using the Pseudo-Routing Number to theIMS 18. The MO CDR (generated by the VMSC) will be discarded usingexisting procedures.

The NGIN/AS 19 will receive the SIP INVITE and, using the correlationIDvalue within the REQUEST-URI be able to determine the call originatorand the original dialled digits and CLIR selection and the VLR address.It may be noted that CLI presentation is dependant upon CAMEL signallingrather than it's conveyance across the international PSTN. Havingidentified the originating user, the Application Server first looks atthe user dialled digits to see if a public translation number exists inthe PNP, if so it applies the translation.

The NGIN/AS shall then perform number normalisation as follows:

Original Dialled Number (as received in the CalledPartyBCDNumberOriginal Normalisation parameter of the IDP Example NOAI function E164formatted number +441635677899 International Original Dialled commencingwith a valid Number needs no country code i.e. where normalisation. themobile user prefixed the E164 formatted number with the “+” sign). Note:The “+” sign shall be removed by the Mobile Handset (and converted bychanging the Called Party Number IE's “Type of Number” to the valueInternational”). Consequently, the original Dialled Number shall reachthe NGIN/AS without the “+” sign International dialling, 00441635677899Unknown The IDAC prefix using the appropriate shall be removedInternational Dialling from the Dialled Access Code applicable Number togenerate to the Country/VPLMN. the E164 number Note: The NGIN/AS is e.g.‘441635677899’ required to determine the appropriate InternationalDialling Access Code(s) eg “00” (as used within most of Europe) or “011

(as used within North America) or “810” (as used in Russia) or “0011

(as used in Australia) etc. for the country/VPLMN being roamed in Localnational dialling to a 037662222 Unknown NDAC prefix is local nationaltelephone removed from number, using the Dialled Number and NationalDialling Access replaced with the code applicable to the E164international UK. country code of the roamed country to form the E164number e.g. ‘97237662222’ Local national dialling to a 37662222 NationalThe E164 country local national telephone code of the UK shall number beprefixed to Dialled Number to form the E164 number e.g. ‘4437662222’.Network short code 121 Unknown Normalisation or translation notnecessary.

indicates data missing or illegible when filed

The Application Server then looks at the translated/null translateddigits to determine if the originating user dialled an internationaltelephone number or UK premium rate telephone number. If so, theApplication Server checks that the originating user has the appropriatecalling privileges by performing a “HLR Test Call”. The ApplicationServer then determines whether the Called Party is the E164msisdn ofanother user belonging to the same customer group. If the Called Partyis the E164msisdn of another user belonging to the same customer group,then on-VPN charging shall apply.

A copy of the call media is sent to the customer's Call Recordingplatform using SIP signalling 25. Within the SIP Call-Info Header (withPurpose=info) supplied within the SIP INVITE or in a separate SIP INFOmessage, the following call related details will be conveyed: “CallType=MO”, “A-Party” {user's E164msisdn}, “DialledDigits” {derived by theAS from the CalledPartyBCDNumber in the IDP} and “B-Party” {derived bythe AS from the outgoing Request-URI}. The answer signal pertaining tothe real call 24 will be signalled to the Call Recording platform usingthe (very delayed) ACK for the 200 Final Response returned by the CallRecording platform for the SIP INVITE (or alternatively using a SIP INFOmessage). If the connection to the Call Recording platform can not beestablished, the Application Server may reject the call attempt orproceed with the call attempt based on customer-determined configurationand an announcement played to the caller. Similarly, if the SIPconnection 25 to the Call Recording platform is ended prematurely, theApplication Server may tear-down the real call (after an announcement isplayed to both parties) or allow the real call to proceed based oncustomer-determined configuration. Being a single SIP connection, theforward and backward transmission paths of the “real call” will bemerged together as a “mono” media delivery to the Call Recordingplatform i.e. speech from the A-party and B-party will be mergedtogether.

The Application Server 19 routes the outgoing call leg of the “realcall” 26 to the intended destination via the PLMN as shown below:

INVITE: Request-URI=E164DestinationAddress, P-Asserted_ID=CallingUser'sE164msisdn, PRIVACY=id (if user has chosen to restrict their CLI),FROM=E164msisdn (else Anonymous@invalid if user has chosen to restricttheir CLI)

It is noted that it is always possible that the real MO call willencounter a call diversion. It is unfortunate that whilst UK ISUPsignalling conveys all of the relevant signalling information pertainingto the diversion encounter, the SIP is unable to properly convey all ofthis information back to the SIP-based Application Server using astandards-based method. Consequently, this document proposes that theSIP>UK ISUP IWF be modified in a proprietary manner in order to map thecontents of the UK ISUP Redirection Number and Call ForwardingInformation parameters (returned in the UK ISUP Address Complete Messageor the Call Progress Message that is used to convey the Alerting event)into a (backward direction) SIP Diversion Header and pass this back tothe Application Server in the “181” Call Forwarding provisionalresponse. Alternatively, the SIP>UK ISUP IWF may use a SIP INFO messageto convey the “backward direction” Diversion Header to the AS. Uponreceipt of this “backward direction” Diversion Header in the 181 CallDiverting provisional response or in the SIP INFO message, the AS willconvey the “backward direction” Diversion Header to the customer's CallRecording Platform in a SIP INFO message.

Upon answer, the answer condition shall be signalled from the AS to theCall Recording Platform in a SIP INFO message. If the called party (orredirection number) is on the originating user's personal white-list thecall will not be recorded, otherwise the call will be recorded. If thecall is to be recorded, customer configuration on the Call Recordingplatform will determine whether an intrusion warning tone eg adouble-beep every ten seconds, is to be provided. Note: if the deliveryof the media is to be achieved using a single call (mono delivery), theintrusion tone will be returned from the Call recording Platform andheard by both the called party and the calling party. However, if thetransmission paths of the calling party and called party are to bedelivered separately (stereo delivery) the call recording platform, thenthe intrusion warning tone should be returned to the called party only.If the intrusion warning tone is to be provided by the Call Recordingplatform, it will commence immediately upon receipt of the answerindication. It is noted that if the call is to another user belonging tothe same customer group, a customer option shall determine whether theintrusion warning tone is provided in this scenario.

The MSC-generated Mobile originated CDR will be priced by a retailbilling system and passed to Central Billing via the CSA feed. This CDRwill not be used for subscriber billing though it may be used to invoicethe service provider.

NGIN shall generate the Mobile Originated CDR that will be used tocharge the originating mobile subscriber through a Central BillingSystem.

Advantages of the described embodiment, compared to existing clientbased solution, include: quicker call set up than the IP Messageprocedure for example less than 500 ms; the system does not require IPdata coverage to avoid DTMF fall back; the system does not rely on IPdata coverage so will not cause “ghost calls” resulting from mobilenetwork congestion; use of IMS AS avoids PSTN interconnect chargeincurred to get the call to the Call Server; the Operator candifferentially charge on-VPN and on-Net mobile calls; the Operator cancharge the mobile originated call directly to the originating user; thesystem Ensures that the user is still a network subscriber; the systemrespects the mobile subscriber's “international calls” and “premium ratecalls” bars; the user's MO calls will be recorded even if they removetheir SIM from their authorised mobile handset; and, if both MobileRoaming (and SMS services) are not required, the solution is SIM basedi.e. it can use any handset because the client is not required.

The call flow of the above detailed exemplary implementation can besummarised as follows. First, the mobile user dials telephone number“01635677899”. The client determines that intervention is not required,thus allowing the mobile to send “01635677899” to the VMSC. The VMSCsends INAP/CAMEL IDP to NGIN. The NGIN returns PRN within INAP/CAMELCONNECT. The VMSC routes call to NGIN. The NGIN reconstitutes call usingCorrelationID within PRN PRN and normalises original dialled digits toE164 format. The AS instructs IMS to initiate conference call to theCall Recording Platform for the MO call. The AS instructs IMS toinitiate real call to “+441635677899”. If the call encounters anyISDN/GSM call forwarding then the AS will notify this to the CallRecording platform. Upon answer, the Call Recording platform willprovide the “intrusion warning tone” to the Called Party only (stereodelivery) or both Called Party and Calling Party (mono delivery).

Mobile Originated Call (Roaming on a CAMEL Compliant PLMN)

FIG. 3 illustrates an exemplary embodiment, in which Mobile Originatedcalls are recorded whilst roaming on a CAMEL compliant PLMN 39. Anexample call flow is as follows. First, the mobile user dials telephonenumber of B 16 (“01635677899”). The client determines that interventionis not required, thus allowing the mobile to send “01635677899” to theVMSC 17 (step 31). The VMSC 17 invokes CAMEL service to AS 19 (step 32).AS 19 returns pseudo-roaming number to the VMSC 17. The VMSC 17 sendscall to international PSTN 40 (step 33). The International PSTN carrierthen sends the call to the home GMSC 41 (step 34). The GMSC 41 thensends the call to the IMS 18 (step 35). The IMS 18 then refers the callto the AS 19 (step 36). The AS 19 instructs the IMS 18 to initiate aconference call to the Media Storage Platform 20 (step 37). The AS 19instructs the IMS 18 to initiate real call to B 16 (“01635677899”, step38). If the call encounters any ISDN/GSM call forwarding then the AS 19will notify this to the Media storage platform 20.

A more detailed embodiment of MO recording on a CAMEL compliant networkwill now be described. This detailed embodiment is illustrated in FIG.4. First, the client will analyse the dialled digits to determinewhether an emergency telephone number, for example, 999, 112, 911 etc.has been dialled. If an emergency telephone number has been dialled, theclient will not modify the dialled digits or participate further in thecall setup but will allow the call to proceed unhindered. If anemergency telephone number has not been dialled, the Client willdetermine what network the mobile subscriber is currently registered on.

Recognising that it's roaming on a PLMN which does support CAMEL, theclient shall instruct the mobile device to send the DTAP SETUP messagewith the Called Party BCD Number information element's Type of Number asdialled eg “international” or “unknown” and Number Digits comprisingonly the “user dialled destination digits.

A SIM toolkit application shall verify that the IMEI corresponds to theuser's registered handset (which has the client installed). If the IMEIis not verified, the call attempt will not be allowed. Otherwise theDTAP SEPUP message is allowed to be sent to the VMSC.

The mobile subscription will have been provisioned with the CAMELservice trigger which will have been stored in the VLR.

The NGIN/AS 19 will receive the INAP/CAMEL IDP 32 for the originatingservice and will store the Called Party BCD Number and Calling PartyNumber parameter (with it's APRI value) and VLR address parametersagainst a correlation Identity number and shall return a Pseudo-routingNumber (comprising <HomeCountryCode> <NationalNumberGroup><Correlationidentity>) within the INAP/CAMEL CONNECT message 32.

In the event that a CAMEL signalling error occurs, the call attemptshall not be allowed to proceed ie the mobile subscriber's CAMEL O-CSIparameter “default ch” shall be configured with the value “RELEASE”.

The VMSC 17 shall route the call using the Pseudo-Routing Number to theIMS 18.

The NGIN/AS 19 will receive the SIP INVITE and, using the correlationIDvalue within the REQUEST-URI, be able to determine the call originatorand the original dialled digits and CLIR selection and the VLR address.It is noted that CLI presentation is dependant upon CAMEL signallingrather than it's conveyance across the international PSTN.

The NGIN/AS 19 shall perform number normalisation as follows:

Original Dialled Number (as received in the CalledPartyBCDNumberNormalisation parameter of the IDP Example Original NOAI function E164formatted number +441635677899 International Original Dialled commencingwith a valid Number needs no country code i.e. where normalisation. themobile user prefixed the E164 formatted number with the “+” sign). Note:The “+” sign shall be removed by the Mobile Handset (and converted bychanging the Called Party Number IE's “Type of Number” to the valueInternational”). Consequently, the original Dialled Number shall reachthe NGIN/AS without the “+” sign International dialling, 00441635677899Unknown The IDAC prefix using the appropriate shall be removedInternational Dialling from the Dialled Access Code applicable Number togenerate to the Country/VPLMN. the E164 number Note: The NGIN/AS is e.g.‘441635677899’ required to determine the appropriate InternationalDialling Access Code(s) eg “00” (as used within most of Europe) or “011

(as used within North America) or “810” (as used in Russia) or “0011

(as used in Australia) etc. for the country/VPLMN being roamed inInternational dialling, 0097237662222 National The IDAC prefix using theappropriate Note: the shall be removed International Dialling networkwould from the Dialled Access Code applicable not expect this Number toto the Country/VPLMN. as a normal generate the E164 Note: The NGIN/AS isarrangement number e.g. required to determine the but have ‘97237662222’appropriate International included it to Dialling Access Code egaccommodate “00” (as used within most possible of Europe) or “011” (asexception used within North cases America) or “810” (as used in Russia)or “0011

(as used in Australia) etc. for the country/VPLMN being roamed inInternational dialling, 0097237662222 International The IDAC prefixusing the appropriate Note: the shall be removed International Diallingnetwork would from the Dialled Access Code applicable not expect thisNumber to to the country/VPLMN. as a normal generate the E164 Note: TheNGIN/AS is arrangement number e.g. required to determine the but haveincluded ‘97237662222’ appropriate International it to accommodateDialling Access Code eg possible “00” (as used within most exception ofEurope) or “011” (as cases used within North America) or “810” (as usedin Russia) or “0011

(as used in Australia) etc for the country/VPLMN being roamed in. Localnational dialling to a 037662222 Unknown NDAC prefix is local nationaltelephone removed from number, using the Dialled Number NationalDialling Access and replaced with code applicable to the the E164country/VPLMN international Note: The NGIN/AS is country code of therequired to determine the roamed country to appropriate National formthe E164 Dialling Access Code eg number e.g. “0 for the country/‘97237662222’ VPLMN being roamed in. Local national dialling to a037662222 National The NDAC prefix is local national telephone Note: theremoved from number network not the Dialled Note: The NGIN/AS is expectthis as Number and required to determine the a normal replaced with theappropriate National arrangement E164 country code Dialling Access Codeeg but have of the roamed “0 for the country/ icluded it to country toform the VPLMN being roamed in. accommodate E164 number e.g. possible‘97237662222’ exception cases Local national dialling to a 37662222National The E164 country local national telephone code of the numberroamed country shall be prefixed to Dialled Number to form the E164number e.g. ‘97237662222’. Network short code 121 Unknown Normalisationor translation not necessary.

indicates data missing or illegible when filed

From this point in the call, the call signalled to the AS 19 where it ishandled as if it had been originated on the home network.

The VPLMN-generated TAP-in CDR will be priced by a retail billing system(based on the roamed network and the +44 pseudo-routing number) andpassed to Central Billing via the CSA feed. This CDR will not be usedfor subscriber billing though it will be used to invoice the serviceprovider.

The NGIN shall generate the Mobile Originated CDR that will be used tocharge the originating mobile subscriber.

Advantages of the described embodiment, compared to existing clientbased solution, include: quicker call set up than the IP Messageprocedure, for example, call setup time typically 750 ms; the operatorcan differentially charge on-VPN and on-Net mobile calls; the operatorcan charge the network originated call leg directly to the originatinguser; the system ensures that the user is still a subscriber; the systemrespects the mobile subscriber's “international calls” bar and “premiumrate calls” bar; the system ensures that the correct SIM is fitted tothe client-enabled mobile handset; and, the system reduces theopportunity for a “man-in-the-middle” eavesdropper to make spoof calls.

The call flow of the above detailed exemplary implementation can besummarised as follows. First, the mobile user dials telephone number“01635677899”. The client determines that USSD intervention is notrequired, thus allowing the mobile to send “01635677899” to the VMSC.The VMSC sends CAMEL IDP to NGIN. The NGIN returns PRN within CAMELCONNECT. The VMSC routes call to the NGIN (via the home PLMN). The NGINreconstitutes call using CorrelationID within PRN and normalisesoriginal dialled digits to E164 format. The AS instructs the IMS toinitiate conference call to the Call Recording Platform for the MO call.The AS instructs IMS to initiate real call to “+491635677899”. It isnoted that if the call encounters any ISDN/GSM call forwarding then theAS will notify this to the customer's Call Recording platform. Uponanswer, the customer's Call Recording platform will provide the“intrusion warning tone” to the Called Party only (stereo delivery) orboth Called Party and Calling Party (mono delivery).

Mobile Originated Call (Roaming a PLMN that does not Support CAMEL).

FIG. 5 illustrates a system for recording Mobile Originated calls whilstroaming in non-CAMEL compliant PLMN where IP data coverage is available.First, the mobile user dials telephone number of B 16 (“01635677899”).The client determines that intervention is required. If an IP datasession has been established, the Client invokes IP Message service 52to AS 19. The AS 19 returns a pseudo-roaming number to the client on themobile device 15. The mobile 15 then sends the pseudo-roaming number tothe VMSC 17 (step 53). The VMSC 17 then sends the call to theinternational PSTN 40. The International PSTN carrier sends the call tothe GMSC 41 (step 54). The GMSC 41 sends the call to the IMS 18 (step55). The IMS 18 then refers the call to the AS 19 which will performcaller authentication (step 56). The AS 19 then instructs the IMS 18 toinitiate a conference call to the Media Storage Platform 20 (step 57).Finally, the AS 19 instructs the IMS 18 to initiate real call to B 16(“01635677899”, step 58). If the call encounters any ISDN/GSM callforwarding then the AS 19 will notify this to the Media storage platform20.

A more detailed alternative exemplary implementation will now bedescribed. This embodiment is not reliant on IP data coverage and isillustrated in FIG. 6. First, the client will analyse the dialled digitsto determine whether an emergency telephone number, for example, 999,112, 911 etc. has been dialled. If an emergency telephone number hasbeen dialled, the client will not modify the dialled digits orparticipate further in the call setup but will allow the call to proceedunhindered. If an emergency telephone number has not been dialled, theclient will determine what network the mobile subscriber is currentlyregistered on.

If the client determines that the mobile is roaming on a foreign PLMN 62that does not support CAMEL then the client will determine whether to(a) prevent the call from proceeding or (b) allow the call to proceedwithout further participating in the call setup or (c) invoke the calllogic for a “Mobile originated call on a foreign PLMN which does notsupport CAMEL” based on a customer determined setting. If the client isconfigured to invoke the call logic for a “Mobile originated call on aforeign PLMN which does not support CAMEL” then: The client will send aUSSD message, via the HLR (not shown), to the NGIN/Application Server19. The USSD message sent by the client will comprise the user dialleddestination digits (including the “+” symbol if dialled) and theidentity of the visited PLMN 62 (the user's E164msisdn and possibly theVLR address will be conveyed to the NGIN/Application server 19 withinthe USSD envelope).

Upon receipt of the USSD Message 63, the NGIN/AS 19 will store: theoriginating mobile subscriber's identity, user dialled digits and theVisited PLMN identity. Note that the NGIN/AS will not be storing theuser's CLIR setting.

The NGIN/Application Server 19 will return, in the USSD response 63, theE164 telephone number (known as a pseudo-roaming number) for the clientto use in order that the circuit switched telephony call can reach theApplication Server 19 and the version number of the current “CAMELcompliant PLMNs list”.

Upon receipt of the USSD response from the NGIN/AS 19, the client willinitiate the call to the pseudo-roaming number into the mobile phone 15.

A SIM toolkit application shall verify that the IMEI corresponds to theuser's registered handset (which has the client installed). If the IMEIis not verified, the call attempt will not be allowed. Otherwise theDTAP SETUP message 61 is allowed to be sent to the VMSC.

The VMSC shall route the call using the Pseudo-Routing Number to the IMS18.

The NGIN/AS 19 will receive the SIP INVITE and, using the correlationIDvalue within the REQUEST-URI, be able to determine the call originatorand the original dialled digits and the VLR address. If the PRIVHeader=id, then the user's CLIR setting=restricted. It is noted that CLIpresentation is dependant upon it's conveyance across the internationalPSTN.

The NGIN/AS shall perform number normalisation as follows:

Original Dialled Number (as Normalisation received in the USSD) Examplefunction E164 formatted number +441635677899 Remove “+” sign commencingwith a valid from Original Dialled country code and prefixed Number.with the “+” sign). International dialling, using 00441635677899 TheIDAC prefix the appropriate International shall be removed DiallingAccess Code from the Dialled applicable to the Country/ Number togenerate VPLMN. the E164 number Note: The NGIN/AS is e.g. ‘441635677899’required to determine the appropriate International Dialling AccessCode(s) eg “00” (as used within most of Europe) or “011” (as used withinNorth America) or “810” (as used in Russia) or “0011” (as used inAustralia) etc. for the country/VPLMN being roamed in Local nationaldialling to a 037662222 NDAC prefix is local national telephone removedfrom number, using the National Dialled Number and Dialling Access codereplaced with the applicable to the country/ E164 international VPLMNcountry code of the Note: The NGIN/AS is roamed country to required todetermine the form the E164 appropriate National Dialling number e.g.Access Code eg “0 for the ‘97237662222’ country/VPLMN being roamed in.Network short code 121 Normalisation or translation not necessary.

The VPLMN-generated TAP-in CDR will be priced by a retail billing system(based on the roamed network and the +44 pseudo-routing number) andpassed to Central Billing via the CSA feed. This CDR will not be usedfor subscriber billing though it will be used invoice the serviceprovider.

The NGIN shall generate the Mobile Originated CDR that will be used tocharge the originating mobile subscriber through the a Central BillingSystem.

The following error conditions may occur:

It is possible that the client was (at the time when the call wasinitiated by the user) not aware that, since the last client update, thevisited PLMN has recently started to support CAMEL. Consequently, theclient will invoke the USSD function to initiate the call and thenvisited PLMN will invoke CAMEL procedures to control the call. Thisarrangement will result in a failed call attempt. However, the USSDfunction will inform the client that a newer version of the CAMEL listexists and this will result in the client initiating a download of thelatest version of the CAMEL list in time for the user to re-attempt thetelephone call.

It is possible that the client was (at the time when the call wasinitiated by the user) not to be aware that since the last clientupdate, the visited PLMN no longer supports CAMEL. Consequently, theclient will not attempt to invoke the USSD function to initiate the call(believing that the visited PLMN will invoke the CAMEL procedure). Thisscenario will result in the call not being recorded. To avoid suchscenario, Operator will sent out an SMS to notify each Client to requesta new CAMEL PLMN list immediately when the client next roams on aforeign PLMN.

The USSD response may also not have been successfully received. In thisscenario, the client will be configured to either abandon the callattempt or proceed with the call attempt using the user dialled digits.If the call is allowed to proceed using the user dialled digits, theTAP-in CDR will be rated within VF UK Gemini and passed to the VF Groupcentral Billing system via the CSA feed where it will be re-rated(because the B-number≠pseudo-routing number) and used for billpresentment

The call flow of the above detailed exemplary implementation can besummarised as follows. First, the mobile user dials telephone number“01635677899”. The client determines the mobile is roaming on a PLMNthat does not support CAMEL so that USSD intervention is required. Theclient instructs the mobile to send a USSD command comprising the userdialled digits to the HLR (not shown). The HLR then forwards the USSD tothe NGIN/AS 19. The NGIN/AS 19 returns a PRN (and CAMEL list version) tothe client. The client instructs the mobile to establish a call usingthe pseudo-roaming number. The VMSC sends the call to the NGIN via thehome network. The NGIN reconstitutes the call using correlationID in PRNand normalises the dialled digits. The AS 19 instructs the IMS 18 toinitiate a conference call to the customer's Call Recording Platform forthe MO call. The AS 19 instructs the IMS 18 to initiate a real call to“+861635677899”. It is noted that if the call encounters any ISDN/GSMcall forwarding then the AS 19 will notify this to the customer's CallRecording platform 20. Upon answer, the Call Recording platform 20 willprovide the “intrusion warning tone” to the Called Party only (stereodelivery) or both Called Party and Calling Party (mono delivery).

In alternative embodiment to that illustrated in FIG. 5, FIG. 7illustrates call recording for MO calls on CAMEL compliant PLMNs were IPdata coverage is not available. First, the mobile user dials thetelephone number of B 16 (“01635677899”). The client determines thatintervention is required. Where an IP data session can not beestablished, the mobile sends the default pseudo-roaming number to theVMSC (step 72). The VMSC 17 sends the call to the international PSTN 40(step 73). The International PSTN carrier sends the call to the homeGMSC 41 (step 74). The GMSC 41 sends the call to the IMS 18 (step 75).The IMS 18 refers the call to the AS 19 (step 76). The AS 19 thenanswers the first call leg. The client sends DTMF digits “01635677899”to the AS which will perform caller authentication (step 77). The AS 19then instructs the IMS 18 to initiate a conference call to the MediaStorage Platform 20 (step 78). Finally, the AS 19 instructs the IMS 18to initiate the real call to B (“01635677899”, step 79). If the callencounters any ISDN/GSM call forwarding then the AS 19 will notify thisto the Media storage platform 20.

Mobile Terminated Call (on Home Network or Roaming).

FIG. 8 illustrates an embodiment of the invention for recording MobileTerminated calls. First, the PSTN subscriber dials mobile telephonenumber 07748328754 belonging to recorded mobile user (step 81). The PSTNsends the call to Operator GMSC 41 (step 82). The GMSC 41 attempts toget location details of the wanted mobile from the HLR 84 but insteadthe HLR 84 returns a TICK service trigger (step 83). The GMSC 41 thensends the call to IMS 18 (step 91). The IMS 18 refers the call to the AS19 (step 85). The AS 19 instructs the IMS 18 to initiate a conferencecall to the Media Storage Platform 20 (step 86). The media storageplatform 20 will return the pre-connection announcement to the caller.The AS 19 instructs the IMS 18 to initiate a real call to “07748328754”(step 87). The GMSC 41 suppresses TICK to get the location details ofwanted mobile from the HLR (step 88). The GMSC 41 then sends the call tothe VMSC 17 (step 89). The VMSC 17 alerts the wanted mobile 16 (step90).

A further, detailed, exemplary implementation of mobile terminated callrecording will now be described. This embodiment is illustrated in FIG.9. On reaching the first Operator gateway MSC 17, an HLR enquiry will beperformed which will identify that the called user has terminatingservice logic which must be performed by the home NGIN/AS 19.

The NGIN/AS 19 will receive the INAP/CAMEL IDP for the terminatingservice and shall return a Pseudo-routing Number (comprising<HomeCountryCode> <OperatorID> <msisdn>) within the INAP/CAMEL CONNECTmessage.

In the event that a CAMEL signalling error occurs, the call attemptshall not be allowed to proceed ie the mobile subscriber's INAP/CAMELT-CSI parameter “default ch” shall be configured with the value“RELEASE”.

The Operator gateway MSC shall route the call using the Pseudo-RoutingNumber to the Operator IMS 18.

The NGIN/AS 19 will receive the SIP INVITE and, using the Pseudo-RoutingNumber value within the REQUEST-URI, be able to determine the wantedmobile subscriber and using the FROM and PAI-header determine the calloriginator and their CLIR selection.

The Application Server 19 may send a copy of the call media to thecustomer's Call Recording platform 20 using SIP signalling. Within theSIP Call-Info Header (with Purpose=info) supplied within the SIP INVITEor in a separate SIP INFO message, the following call related detailswill be conveyed: “Call Type=MT”, “A-Party” {derived by the AS from theincoming From header} and “B-Party” {derived by the AS from the incomingRequest-URI}. The answer signal pertaining to the real call will besignalled to the Call Recording platform using the (very delayed) ACKfor the 200 Final Response returned by the call and SMS storage platformfor the SIP INVITE (or alternatively using a SIP INFO message). If theconnection to the Call Recording platform can not be established, theApplication Server may reject the call attempt (and an announcementplayed to the caller) or proceed with the call attempt based on acustomer-determined configuration. Similarly, if the SIP connection tothe Call Recording platform is ended prematurely, the Application Servermay tear-down the real call (after an announcement has been played toboth parties) or allow the real call to proceed based oncustomer-determined configuration. Being a single SIP connection, theforward and backward transmission paths of the “real call” will bemerged together as a “mono” media delivery to the Call Recordingplatform i.e. speech from the A-party and B-party will be mergedtogether.

The Application Server routes the “real call” to the called mobile userin any PLMN 92 via the home PLMN using TICK suppress prefix (being thevalue “8777”).

INVITE: Request-URI=+8777 (being a spare international country code)followed by CalledUser′sMSISDN, P-Asserted ID=Caller′sE164CLI,PRIVACY=id (if user has chosen to restrict their CLI), FROM=E164msisdn(else Anonymous@invalid if user has chosen to restrict their CLI)

If the call is to be recorded, customer configuration on the CallRecording platform will determine whether the intrusion warning tone,for example, a double-beep every ten seconds, informing the both thecalling party and the called party that their call is being recorded, isto be provided. If the intrusion warning tone is to be provided by theCall Recording platform 20, it will commence immediately upon receipt ofthe answer indication. It is noted that if the Calling Party is anothermobile user belonging to the same customer group, configuration shalldetermine whether the intrusion warning tone associated with the MT callleg shall be provided.

If the media delivery to the Call Recording Platform is stereo delivery,then the intrusion warning tone should only be returned to theoriginating party.

The client is always in passive mode for MT calls, so the inbound callis always allowed to alert the mobile.

Where the called mobile user has an active GSM Call Forward diversionthat is invoked or where the called mobile user invokes Call Deflection,the GMSC (for the unconditional diversion and for all conditionaldiversions and Call Deflection whilst roaming) or the VMSC (for allconditional diversions and Call Deflection whilst on the home network)will invoke INAP/CAMEL the OICK triggered SIP INVITE to the ApplicationServer, in order that the Mobile Call Forwarding call may also berecorded (as a separate call)

It is unfortunate that whilst UK ISUP signalling conveys all of therelevant signalling information pertaining to the diversion encounter,the SIP>UK ISUP interworking function is unable to properly convey allof this information back to the SIP-based Application Server.Consequently, this embodiment proposes that the SIP>UK ISUP IWF bemodified in a proprietary manner in order to map the contents of the UKISUP Redirection Number and Call Forwarding Information parameters(returned in the UK ISUP Address Complete Message or the Call ProgressMessage that is used to convey the Alerting event) into a (backwarddirection) SIP Diversion Header and pass this back to the ApplicationServer in the “181” Call Forwarding provisional response. Alternatively,the SIP>UK ISUP IWF may use a SIP INFO message to convey the “backwarddirection” Diversion Header to the AS. Upon receipt of this “backwarddirection” Diversion Header in the 181 Call Diverting provisionalresponse or in the SIP INFO message, the AS will convey the “backwarddirection” Diversion Header to the customer's Call Recording platform ina SIP INFO message.

In the event that the MT call encounters a Call Forward condition, thecustomer's Call Recording platform 20 shall maintain the SIP connectionfrom the AS but shall not record the MT call leg nor provide theintrusion warning tone, as these functions will be performed by theMobile Call Forward call logic instead

This exemplary embodiment has the following advantages compared to thecurrent client based solution: significantly quicker call set up byavoiding the first GSM mobile paging sequence (saves at least 4.5seconds, and significantly more if the user is roaming); more efficientcall routing in the mobile network—the call only goes to the user'svisited MSC once; the Call Forward on Busy call charge is avoided by theterminating mobile user; use of IMS AS avoids PSTN interconnect chargeincurred by the operator to get the call to the Call Server, use of IMSAS avoids PSTN access charge incurred by customer to get the call to thewanted user; ensures that the user is a subscriber; the user's MT callswill be recorded even if they remove their SIM from their authorisedmobile handset and put it in an unauthorised handset; if both MobileRoaming (and SMS services) are not required, the solution is SIM basedie it can use any handset because the client is not required; becauseSIP is used by the Application Server (rather than a “tapped ISDN30”line), calls that are to be deposited to the called user's voicemail boxdo not need to be sent out towards the called user again (this avoids asecond Call Forwarding charge being incurred by the called mobile userand avoids the PSTN conveyance charge towards the called mobile user);supports GSM Call Waiting; supports GSM Call Forwarding services eg CFU,CFB, CFNR, CFNRc & CD, to any destination; supports GSM Call Transfer;supports GSM 3-Party calls; supports GSM Conference Calls; and, supportsNetwork voicemail.

The call flow of the above detailed exemplary implementation can besummarised as follows. First, the PSTN subscriber dials mobile telephonenumber belonging to recorded mobile user. Next, the PSTN sends the callto Operator GMSC. The GMSC attempts to get the location details of thewanted mobile from the HLR but instead the HLR returns a INAP/CAMELterminating call service trigger. The GMSC sends INAP/CAMEL IDP for theterminating call to NGIN/AS. The NGIN/AS returns CONNECT containing PRN(comprising OpCoIdentity and msisdn). The GMSC sends the call to theIMS. The IMS refers the call to NGIN/AS and uses PRN to identify wantedmobile. The AS instructs the IMS to initiate a “conference call” to theCall Recording Platform for the MT call. The NGIN/AS instructs the IMSto initiate real call to called mobile (with instruction to suppress INterminating call service trigger). The GMSC suppresses TICK and to getlocation details of the wanted mobile from the HLR. Finally, uponanswer, the Call Recording platform will provide the “intrusion warningtone” to the Calling Party only (in ‘stereo delivery’ mode) or bothCalling Party and Called Party (in ‘mono delivery’ mode). It is notedthat if a GSM call forward condition is encountered, the MT leg need notbe recorded as the Mobile Call Forwarded call will be recorded.

Mobile Call Forwarding call

FIG. 10 illustrates a Mobile Diverted call, that is, an MT call thatencounters a GSM Call Forward condition. First, the PSTN subscriberdials mobile telephone number 07748328754 belonging to recorded mobileuser (step 101). The PSTN sends the call to Operator GMSC 41 (step 102).The GMSC 41 attempts to get location details of wanted mobile from theHLR but instead the HLR returns a TICK service trigger (step 103). TheGMSC 41 sends the call to the IMS 18 (step 104). The IMS 18 refers thecall to the AS 19 (step 105). The AS 19 instructs the IMS 18 to initiatea conference call to Media Storage Platform 20 (step 106). The mediastorage platform 20 will return the pre-connection announcement to thecaller. The AS 19 instructs the IMS to initiate real call to“07748328754” (step 107). The GMSC 41 suppresses TICK and gets thelocation details of the wanted mobile from the HLR 84 (step 108). TheHLR 84 returns a Call Forward Unconditional instruction. The GMSCoriginates a CFU call leg to the IMS 18 (step 109). The IMS 18 thenrefers the call to the AS 19 (step 110). The AS 19 instructs the IMS 18to initiate the call to the user nominated Call Forward destination 112(step 111). The AS 18 will notify the GSM Call Forward encounter to theMedia storage platform 20.

This embodiment has the following advantages compared to known clientbased solutions: the system provides the customer with the option not torecord mobile diverting calls; the operator can charge the mobilediverted call directly to the originating user; the operator candifferentially charge on-VPN and on-Net mobile diverted calls; thesystem ensures that the user is still a subscriber; the system respectsthe mobile subscriber's “international calls” and “premium rate calls”bars; if both Mobile Roaming and SMS services are not required, thesolution is SIM based i.e. it can use any handset because the client isnot required; the system supports GSM Call Forwarding services eg CFU,CFB, CFNR, CFNRc & CD, to any destination; and, supports Networkvoicemail.

A further exemplary embodiment will now be described. Where the calledmobile user has an active GSM Call Forward diversion that is invoked orwhere the called mobile user invokes Call Deflection which results incall forward on Busy, the GMSC (for the unconditional diversion and forall conditional diversions and Call Deflection whilst roaming) or theVMSC (for all conditional diversions and Call Deflection whilst on thehome network) will invoke the INAP/CAMEL trigger for the Mobileoriginated Call Forwarding call.

The NGIN/AS will receive the INAP/CAMEL IDP for the Call ForwardingService and will store the Called Party Number and Calling Party Numberparameter (with it's APRI value) against a correlation Identity numberand shall return a Pseudo-routing Number (comprising <HomeCountryCode><NationalNumberGroup> <Correlationidentity>) within the INAP/CAMELCONNECT message.

In the event that a INAP/CAMEL signalling error occurs, the call attemptshall not be allowed to proceed ie the mobile subscriber's CAMEL O-CSIparameter “default ch” shall be configured with the value “RELEASE”.

The VMSC shall route the call using the Pseudo-Routing Number to theIMS.

The NGIN/AS will receive the SIP INVITE and, using the correlationIDvalue within the REQUEST-URI, be able to determine the call originator(and their CLIR selection), Last Diverting party and the Forwardingnumber.

The Application Server shall determine that Mobile Call Forwarding calllogic shall be applied because the OICK triggered SIP INVITE willinclude the SIP Diversion Header. The Application Server then looks atthe translated/null translated digits to determine if the originatinguser diverted to an international telephone number or UK premium ratetelephone number. If so, the Application Server checks that theoriginating user has the appropriate calling privileges by performing a“HLR Test Call”. The Application Server then determines whether theCalled Party is the E164msisdn of another user belonging to the samecustomer group. If the Called Party is the E164msisdn of another userbelonging to the same customer group, then on-VPN charging shall apply.

The Application Server shall send a copy of the call media to thecustomer's Call Recording platform using SIP signalling. Within the SIPCall-Info Header (with Purpose=info) supplied within the SIP INVITE orin a separate SIP INFO message, the following call related details willbe conveyed: “Call Type=MCF”, “A-Party”, “Diverting Party” “C-Party” and“Diversion Type” {derived by the AS from the incoming DiversionHeader}”. The answer signal pertaining to the real call will besignalled to the Call Recording platform using the (very delayed) ACKfor the 200 Final Response returned by the Call Recording platform forthe SIP INVITE (or alternatively using a SIP INFO message). If theconnection to the Call Recording platform for the MCF Call can not beestablished, the Application Server may reject the call attempt (and anannouncement played to the caller) or proceed with the call attemptbased on a customer-determined configuration for the MCF scenario.Similarly, if the SIP connection to the Call Recording platform for theMCF call is ended prematurely, the Application Server may tear-down thereal call (after an announcement has been played to both parties) orallow the real call to proceed based on customer-determinedconfiguration for the MCF scenario. Being a single SIP connection, theforward and backward transmission paths of the “real call” will bemerged together as a “mono” media delivery to the Call Recordingplatform i.e. speech from the A-party and B-party will be mergedtogether.

The Call Recording Platform shall return the post connectionannouncement to both the calling party and the called party.

The Application Server routes outgoing call leg of the “real call” tothe intended diversion destination via the home PLMN.

It is noted that it is always possible that the real MCF call willencounter a further call diversion. It is unfortunate that whilst UKISUP signalling conveys all of the relevant signalling informationpertaining to the diversion encounter, the SIP>UK ISUP interworkingfunction is unable to properly convey all of this information back tothe SIP-based Application Server. Consequently, this document proposesthat the SIP>UK ISUP IWF be modified in a proprietary manner in order tomap the contents of the UK ISUP Redirection Number and Call ForwardingInformation parameters (returned in the UK ISUP Address Complete Messageor the Call Progress Message that is used to convey the Alerting event)into a (backward direction) SIP Diversion Header and pass this back tothe Application Server in the “181” Call Forwarding provisionalresponse. Alternatively, the SIP>UK ISUP IWF may use a SIP INFO messageto convey the “backward direction” Diversion Header to the AS. Uponreceipt of this “backward direction” Diversion Header in the 181 CallDiverting provisional response or in the SIP INFO message, the AS willconvey the “backward direction” Diversion Header to the customer's CallRecording platform in a SIP INFO message.

The MSC-generated Mobile Call Forwarded CDR will be priced by a retailbilling system and passed to Central Billing via a CSA feed. This CDRwill not be used for subscriber billing though it will be used invoicethe service provider.

NGIN shall generate the Mobile Call Forwarded CDR that will be used tocharge the originating mobile subscriber through the a Central BillingSystem.

The call flow of the above detailed exemplary implementation can besummarised as follows. The process begins with the same call sequence asfor MT calls. However, instead of the GMSC getting the location detailsof the wanted mobile from the HLR, the GMSC/VMSC will invoke the GSMCall Forward supplementary service which will, in turn trigger theINAP/CAMEL originating call service trigger with call type. The GMSCsends INAP/CAMEL IDP for the call forwarding call to NGIN/AS. TheNGIN/AS returns CONNECT containing PRN (comprising OpCoIdentity andmsisdn). The GMSC sends the call to IMS. The IMS the refers the call tothe NGIN/AS, and uses the PRN to identify the wanted mobile. The AS theninstructs the IMS to initiate a “conference call” to the Call RecordingPlatform for the MCF call. The NGIN/AS instructs the IMS to initiatereal call to called mobile (with instruction to suppress IN terminatingcall service trigger). The GMSC the suppresses TICK and gets thelocation details of the wanted mobile from the HLR. On ISUP ACM the factthat the call encountered a Call forward will be returned back from theterminating switch and this will be conveyed back to the NGIN/AS. TheNGIN/AS may notify this to the Call Recording platform and may releasethe conference call-leg for the MT Call recording platform. Upon answer,the Call Recording platform will provide the “post-connectionannouncement” to both the Calling Party and Called Party. It is notedthat if the call encounters any subsequent ISDN/GSM call forwarding thenthe AS will notify this to the Call Recording platform.

“Intrusion Warning Tone” and the “Post-Connection Announcement”

In order to comply with privacy requirements, it may be necessary forall parties involved in a call that's being recorded to be made aware ofthis situation. For this reason, this design includes the provision ofan “Intrusion warning tone” and, for some call scenarios a“Post-connection announcement”.

In the two very simple call scenarios ie the MO call and the MT call, atleast one party in the call is knowledgeable as to the significance ofthe intrusion warning tone, and this party can explain the significanceof the intrusion warning tone to the other party, if this becomesnecessary. Specifically, for an MO call, intrusion warning tone should,where ever possible, be provided to the B-Party only whilst for a MTcall, intrusion warning tone should, wherever possible, be provided tothe A-party only.

In the Mobile Call Forward call scenario, it is likely that neither theoriginating party (A-party) or the destination party (C-party) would beknowledgeable as to the significance of any intrusion warning tone whenthe call is being recorded because of a diverting mobile user (B-party).Hence the requirement for the “post-connection announcement” to notifyboth the originating party and destination party that (because of thediverted mobile call) their call is being recorded on behalf of athird-party mobile subscription that is not participating in the callpath (but is responsible for the diversion leg of the call). Subsequent,to the “post-connection announcement”, no “Intrusion Warning Tone” shallbe provided for call.

Language selection of the “post-connection announcement” may be appliedbased on the preference of the diverting mobile user or being based onthe international country code of the caller's CLI.

The call scenario that follows, is extreme but helps to explain thesituation: Three mobile users, “User A1”, “User B2” and “User C3” eachhave a mobile which is subject to call recording and are employed bythree different companies 1, 2 and 3 respectively. “User A1” calls “UserB2” (who has set a Call Forward on No Reply to “User C3”). When “UserC3” answers the call, the post-connection announcement will be providedto both “User A1” and “User C3” in relation to the MCF call of “UserB2”. Intrusion warning tone will be provided to “User A1” in relation tothe MT call of “User C3”. Intrusion warning tone will be provided to“User C3” in relation to the MO call of “User A1”.

It is noted that if only post-connection announcements were deployed forMO, MT and MCF calls, these announcements would interfere with eachother in complex call scenarios. Furthermore, The use of pre-connectionannouncements for MT calls might interfere with other networkannouncements such as “The mobile that you have called is switched off .. . ”.

Mobile Originated and Mobile Terminated SMS Functionality

The exemplary SMS recording is illustrated in FIG. 11 and is proposed asfollows: (a) where IP data coverage exists on the home PLMN 27, a copyof the MO or MT SMS is generated by the client on mobile device 15 andsent to the centralised SMS distribution server 113 by an IP Message viathe GGSN 116 as part of the packet switched PS network 115. Where IPdata coverage is not available or the mobile is roaming on a foreignPLMN 39, the mobile client will create a “close replica” SMS messagefrom the MO or MT SMS and sends it to an SMS aggregator 117 who willsend it to a centralised SMS distribution server 113, which willnormalise the SMS into an exact replica of the original SMS and send itto the customer's SMS storage system 20. Where data is not available inthe home PLMN, an SMS IP gateway 114 may be used to forward the data tothe SMS aggregator 117. For bill presentment purposes, the RetailBilling System shall overwrite the SMS aggregator's service number withgeneric text like “Copied SMS sent to your SMS recording server”.

The client will hold a network white-list to prevent SMS messagesrelating to Voicemail notifications and roaming SMS welcome messagesbeing recorded (and, even worse, at the user's expense).

The SMS recording and storage platform will discard any MO SMS that havebeen sent to a user declared white-list destination. Similarly, the SMSrecording and storage platform will discard any MT SMS that have beensent from a user declared white-list source.

Storage of MO SMS and MT SMS may only be performed if the other party isnot on the user's personal white-list i.e. the client may not hold theuser's personal white-list.

Voicemail Services

The embodiments described above use network voicemail. In recognitionthat the user may select SMS as the Message Deposit Notification method,the SMS sender address of the Network Voicemail system may be includedin the Client's “SMS sender” generic white-list

Although recording of the Voicemail deposit will be performed at thetime of the deposit, not means will exist to determine whether thesubscriber ever retrieved the message if the Voicemail system allowedthe user to retrieve their messages from any telephone device.Consequently, each mailbox must be configured so as to prevent Voicemailaccess from any telephony device other than the mobile subscriber'smobile phone.

Although Voicemail retrieval will only be allowed from the mobilesubscriber's mobile phone, direct message deposits will not enable theidentity of the caller to be determined. Consequently each mailbox mustbe configured so as to prevent direct voicemail deposit.

Because Voicemail outdialling to return calls will not enable toidentity of the destination to be determined, each mailbox must beconfigured so as to prevent outdialling to return calls.

Disaster Over-Ride Arrangements

If the Call Recording platform (or access to it) fails, and this isresulting in the users' telephony calls failing to establish then theMobile VPN configuration in the AS may be changed (from “CompelledRecording” to “Best Endeavours Recording”).

Client Configuration and Updating

The client may only accept activations, deactivations and updates (bySMS) from the specified centralised client management server 121depicted on FIG. 12. The client may pull the most current “CAMELcompliant PLMNs list” from the centralised management server 121 (by IPMessaging) after it has learnt (from the USSD response from the NGIN)that a newer version of the list exists.

In the event that a PLMN that was once declared as “CAMEL compliant” isno longer to be regarded as “CAMEL compliant”, an SMS will be requiredto be sent to all clients, to prompt the client to obtain a new “CAMELcompliant PLMN list” when the client subsequently determines that it isroaming.

Mobile Handset Replacement

Prior to activation of the client, details of the IMEIs pertaining toall of the Smart phone handsets that have been loaded with clientsoftware will be declared on the call and SMS Storage platform, by anadministrator 125.

Upon client activation, details of the user's IMEI may be stored on thecall and SMS Storage Platform (along with the fact that the client isnow active). If the IMEI being used by the mobile user's SIM is not onethat has already been declared, then the call and SMS Storage Platformwill raise an alarm event and may notify the administrator 125 (byemail). This is illustrated in FIG. 13 where the mobile device isregistered with the circuit switched network 120.

In the event that a user subsequently removes their SIM from theiroriginal Smart phone and installs it into another mobile phone, the HLR84 may notify the Centralised SMS distribution server 113.

The centralised SMS distribution server will then notify the call andSMS Storage Platform. If the new IMEI is one that has previously beendeclared (and has an active client) then the event will be loggedagainst the user but no notification will be generated, If the new IMEIis one that has previously been declared (but does not currently have anactive client) then the call and SMS Storage Platform will send aninstruction to the Centralised Client Management server to send a newactivation SMS to the mobile user's MSISDN and will raise an alarm eventand notify the customer administrator by email (the alarm event will beended when the client activation attempt is successfully acknowledged bythe newly activated client). If the new IMEI is not one which hasalready been declared, then the customer's call and SMS Storage Platformwill raise an alarm event and will notify the customer administrator (byemail), i.e. it is permitted for the user to change the Smart Phone thattheir SIM is inserted into, provided that the new Smart Phone has beendeclared, i.e. authorised.

User Provisioning

FIG. 12 illustrates how a user may be provisioned in the system. Geminimay provision the CTN using existing provisioning procedures to ISAAC,re-using a new Mobile Tariff Code and using a VPN-name based on thesubscriber's CORP_ID. A new feature named “Handset Client” may beapplied to the mobile subscription. ISAAC 123 may provision the MSISDNinto the HLR 84 using a new HLR profile. ISAAC may provision the MSISDNto ASAP 122 (existing). The new Client feature will be included in theprovisioning instruction sent to ASAP 122. ASAP 122 may provision theMSISDN into the NGIN/AS and provision the MSISDN into a new centralisedclient management server 121.

The centralised client management server may provision the MSISDN intothe centralised SMS distribution server 113 and may send the clientactivation SMS message (with the appropriate configuration) to themobile subscriber to activate the client as illustrated in FIG. 14. Itis noted that the centralised client management server 121 may resendthe client activation SMS or may send the client deactivation SMS uponreceipt of an instruction from the customer's CPE-based/Hosted call andSMS storage system. The centralised SMS distribution server 113 maynotify the CPE-based/Hosted call and SMS storage server of the new user.Until the client has acknowledged it's activation, the CPE-based/Hostedcall and SMS storage server may regard the user as “partiallyprovisioned”. Upon activation, the client will notify the centralisedclient management server 121 of the handset IMEI. The centralised clientmanagement server 121 may update CUR 141 and the centralised SMSdistribution server with the client details and IMEI.

The centralised SMS distribution server may update the CPE-based/Hostedcall and SMS storage server with the IMEI details of the user.

User White-List Numbers

With the exception of a few generic telephone numbers and a few genericSMS senders eg “Network Voicemail Deposit” SMS notifications and“Welcome” SMS notifications sent to roaming subscribers common to allusers, the client and the mobile network will handle all MO & MT callsand all MO & MT SMS as if they are to be recorded. However, the call andSMS recording and storage platform can be configured to discard the callmedia and SMS when the other party is declared to be one of the user'swhite-listed (personal) contacts.

It may not be possible for a white-list number to be that of anothermobile user in the same company group. Any white-list entry thatsubsequently becomes a mobile user in the same company group shallautomatically be deleted as a white-list entry.

Security Issues:

Whilst the IMEI reporting function can identify instances when a mobileuser has placed their SIM into a mobile phone that has a different IMEI,the IMEI function may not be unable to identify instances when a mobileuser has placed their SIM into a mobile phone that has an IMEI spoofedto be that of the user's authorised mobile phone. Although initiallyintended to address the specific needs of sections of the banking andfinance industry that are covered by the FSA, it is possible that otherenterprise customers my take up the product for quality control/orderverification purposes. Consequently, credit card information may berecorded and stored on the operator hosted call and SMS storage system.

Whilst not being as independent of user honesty as an entirelynetwork-based solution, the present network-assisted solution is able togenerate event reports of SIM/IMEI changes in order to identifyinstances when the mobile subscriber placed their SIM into an“unauthorised” mobile phone. The solution offers awareness of the IMEIof the mobile handset that the mobile subscriber's SIM is being usedwith. This capability allows the customer to be notified when a userinstalls their SIM into an unauthorised mobile handset.

GSM/3G Services not Supported

If the MRF is used to provide the “conference leg” to the call Recordingplatform, the call content will be recorded in “mono”, i.e. the speechof both A-party and B-party is merged together. Consequently, circuitswitched data calls and facsimile calls may not be properly recorded.Therefore, mobiles subscribing to the Voice & SMS mobile call recordingservice must not be provisioned with any Bearer Service associated withCSD or video telephony or any Tele-service associated with facsimile andmust not be provisioned with secondary MSISDNs associated with theseservices.

As a result of the inability of the solution to record MMS, mobilessubscribing to the Voice & SMS mobile call recording service may not beprovisioned with the ability to send or receive MMS. Any MMS messagesthat are sent to the mobile subscriber may be notified to the mobilesubscriber by SMS (with an http link to an internet address).

Call Charging

The Mobile Originated CDR or Mobile Call Forward CDR generated by theNGIN/AS may be used to derive the end-user call charge using the VLR toidentify the originating PLMN/Country and the E164 telephone number toidentify destination (and whether the destination was “on-VPN”) and calldate/time and duration. The MSC-generated MO CDR (on Home PLMN) andForeign PLMN-generated TAP CDR (when roaming) shall be used to invoicethe service provider. The MSC-generated Roamed Call Forward shall beused to invoice the service provider and shall be used to derive theend-user call charge.

Client

Although the present description describes an example of commissioning aMobile Client specifically for “call and SMS Recording”, instead a known“Rich Communications Suite enhanced” (RCSe) Client could be amended toperform the functions designated for the “Client”. This would broadenthe choice of handset devices available to the user. It will beunderstood that other implementations the described client are possible,as long as the implementation provides the described functionality.

1. A mobile telecommunications device configured to connect to a PublicLand Mobile Network (PLMN), wherein the device is adapted to facilitatecreation of a record of an original Short Message Service (SMS) messagesent or received by the device, by: sending an IP data messagecorresponding to the original SMS message towards an SMS storage system,where the connected PLMN is a home PLMN and where IP data coverage isavailable, and, sending a replica of the original SMS message towardsthe SMS storage system where the device is roaming or where IP datacoverage is not available.
 2. A device according to claim 1, in which,if an origination or destination of the SMS matches one of apredetermined list of originations or destinations stored on the mobiledevice, the device does not store the SMS.
 3. A device according toclaim 1, in which the device is further adapted to: identify if theconnected PLMN supports Customised Applications for Mobile networkEnhanced Logic (CAMEL); and, upon detecting an attempt to initiate acall to a dialled number, if the connected PLMN does not support CAMEL,prevent the call from proceeding.
 4. A device according to claim 1, inwhich the device is further adapted to: identify if the connected PLMNsupports Customised Applications for Mobile network Enhanced Logic(CAMEL); and upon detecting an attempt to initiate a call to a diallednumber, if the connected PLMN does not support CAMEL, the device isadapted to: send a data message to an IP Multi-media Sub-system (IMS),including the dialled number; receive a pseudo-roaming number; and,initiate a call to the pseudo-roaming number.
 5. A device according toclaim 4, in which the data message is a session-based data message.
 6. Adevice according to claim 5, in which the data message is a UnstructuredSupplementary Service Data (USSD) message.
 7. A device according toclaim 3, in which the identifying if the connected PLMN supports CAMELcomprises evaluating the connected PLMN against a list of PLMNs thatsupport CAMEL stored on the mobile device.
 8. A device according toclaim 7, in which the mobile device is adapted to store the list uponreceipt of the list from an IMS.
 9. A device according to claim 3, inwhich, if the dialled number matches one of a predetermined list ofnumbers stored on the mobile device, the mobile device is adapted toallow the call to proceed irrespective of whether the PLMN supportsCAMEL.
 10. A method of creating a record of an original Short MessageService (SMS) message sent or received by a mobile device connected to aPublic Land Mobile Network (PLMN), the method comprising: sending an IPdata message corresponding to the original SMS message towards an SMSstorage system, where the connected PLMN is a home PLMN and where IPdata coverage is available, and, sending a replica of the original SMSmessage towards the SMS storage system where the device is roaming orwhere IP data coverage is not available.
 11. A method according to claim10, wherein an SMS distribution server receives the replica SMS message,and the method further includes: the SMS distribution server normalisingthe replica SMS message into an SMS message exactly corresponding to theoriginal SMS message and then sending the normalised SMS message to theSMS storage system.
 12. A method according to claim 10, in which, if anorigination or destination of the SMS matches one of a predeterminedlist of originations or destinations stored on the mobile device, notstoring the SMS.
 13. A method according to claim 10, further comprising:identifying if the connected PLMN supports Customised Applications forMobile network Enhanced Logic (CAMEL); and, upon detecting an attempt toinitiate a call to a dialled number, if the connected PLMN does notsupport CAMEL, preventing the call from proceeding.
 14. A methodaccording to claim 10, further comprising: identifying if the connectedPLMN supports Customised Applications for Mobile network Enhanced Logic(CAMEL); and, upon detecting an attempt to initiate a call to a diallednumber, if the connected PLMN does not support CAMEL: sending a datamessage to an IP Multi-media Sub-system (IMS), including the diallednumber; receiving a pseudo-roaming number; and, initiating a call to thepseudo-roaming number.
 15. A method according to claim 14, in which thedata message is a session-based data message.
 16. A method according toclaim 13, in which the data message is an Unstructured SupplementaryService Data (USSD) message.
 17. A method according to claim 12, inwhich the identifying if the connected PLMN supports CAMEL comprisesevaluating the connected PLMN against a list of PLMNs that support CAMELstored on the mobile device.
 18. A method according to claim 17, furthercomprising storing the list upon receipt of the list from an IMS.
 19. Amethod according to claim 12, further comprising, if the dialled numbermatches one of a predetermined list of numbers stored on the mobiledevice, allowing the call to proceed irrespective of whether the PLMNsupports CAMEL.
 20. A computer readable medium comprising instructionswhich when executed by a processor of a mobile device being connected toa Public Land Mobile Network (PLMN), cause the mobile device to carryout the method of claim 10.